After preparing a page for page-in, allow immediate fill-in of the page contents
authorAndres Lagar-Cavilla <andres@lagarcavilla.org>
Thu, 1 Dec 2011 18:14:24 +0000 (18:14 +0000)
committerAndres Lagar-Cavilla <andres@lagarcavilla.org>
Thu, 1 Dec 2011 18:14:24 +0000 (18:14 +0000)
commit26a5c829c8e6c2379fc45529accddf8b65fbbcef
tree4b82488641d71d5535058e414893d9abe1754362
parentc93217edc3e3b904491df571c51f1f2588a58e58
After preparing a page for page-in, allow immediate fill-in of the page contents

p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for that page.
Foreign mappings of the gfn will now succeed. This is the key idea, as
it allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
xen/arch/x86/mm/mem_event.c
xen/arch/x86/mm/mem_paging.c
xen/arch/x86/mm/p2m.c
xen/include/asm-x86/p2m.h
xen/include/public/domctl.h